Can't we put this behavior behind a flag? This seems pretty risky tbh.

What kind of flag are you thinking about?

@Ma27 This behavior is already behind the flag boot.zfs.enableUnstable which I think is sufficient, especially in conjunction with the warning message in the option text and the documented change in the release notes.

Considering how zfsUnstable is used (e.g. it points to stable 2.1 on 21.05 because zfsStable is still 2.0.5 which doesn't support newer kenrels) I disagree.

The version will have already passed an extensive test suite, but it is more likely to hit an undiscovered bug compared to running a released version of ZFS on Linux.

Throwing away all compatibility checks IMHO contradicts with this.

What kind of flag are you thinking about?

Idk, linuxPackages.zfs.override { disableCompatibilityCheck = true; } for instance?

Idk, linuxPackages.zfs.override { disableCompatibilityCheck = true; } for instance?

Where should this go inside configuration.nix then? This requires a rather complicated overlay, plus it will probably trigger a rebuild.

This is the minimal overlay that you need to override something in zfsUnstable, because you need to override both, the kernel module and the userspace tools.

{ config, pkgs, ... }:

{
  boot.kernelPackages = pkgs.linuxPackages_latest;
  boot.zfs.enableUnstable = true;
  nixpkgs.overlays = [
    (self: super: {
      linuxPackages_latest = super.linuxPackages_latest.extend (linuxPackagesSelf: linuxPackagesSuper: {
        zfsUnstable = linuxPackagesSuper.zfsUnstable.override {
          #...
        };
      });

      zfsUnstable = super.zfsUnstable.override {
        # ...
      };
    })
  ];
}

Considering how zfsUnstable is used (e.g. it points to stable 2.1 on 21.05 because zfsStable is still 2.0.5 which doesn't support newer kenrels) I disagree.

I disagree with this statement. The way I see zfsUnstable being used is that people who want to run the latest kernel are forced to switch to zfsUnstable for that support. However, upstream is often rather slow with marking their versions (including release candidates) as compatible with the latest kernel versions. This often results in a dilemma which we are in again right now, because Linux 5.15 has been released but there is no release or rc of OpenZFS that is marked as compatible with 5.15. By trying out it was discovered that the current ZFS 2.1.1 is probably compatible with 5.15 anyway, so it was proposed to just bump the version check #145458. In my opinion this is inconsequential and wrong, because now the compatibility check is complete bogus and the user is not even warned about it.

This is the minimal overlay that you need to override something in zfsUnstable, because you need to override both, the kernel module and the userspace tools.

I'd be fine with this if it gets documented somewhere.

In my opinion this is inconsequential and wrong, because now the compatibility check is complete bogus and the user is not even warned about it.

Well, if users want to use zfs against a kernel that's (not yet) officially supported, they are free to do so via e.g. an overlay as you demonstrated it above. But we as a distro should adhere to what upstream says IMHO.

Well, if users want to use zfs against a kernel that's (not yet) officially supported, they are free to do so via e.g. an overlay as you demonstrated it above.

That used to be my stance as well but recently every two weeks or so someone shows up whining that they cannot use the latest kernel with ZFS.

FWIW, I encountered this issue while trying to build an ISO image with the installation-cd-minimal-new-kernel profile, since the base profile enables ZFS support.

whining that they cannot use the latest kernel with ZFS.

tbh that's better than people whining about fs issues because NixOS didn't stop them from installing zfs with an incompatible kernel. Yes, it may be fine in most of the cases if only the compatible version-range has to be updated, but that's not always the case and we as a distro shouldn't make guarantees upstream can't make (yet). I have to admit that I didn't know of the overlay-approach you posted above, so I'd suggest we put this into the manual and point everyone to it if they're unhappy.